[1/3] arch/xtensa: Provide vfork() by casaroli · Pull Request #19795 · apache/nuttx

casaroli · 2026-08-11T13:43:56Z

Summary

Split from #19772, part 1 of 3, as asked in review.

It gives Xtensa vfork() and nothing else. No MMU, no address environment, no chip code.

up_fork(bool vfork) is the architecture half of the primitive introduced by #19562. The child gets its own stack holding a relocated copy of the part of the parent's that is in use, and resumes where the caller would have returned.

Two paths reach it. A flat build calls in directly, so the caller's registers are taken at the call. A build with system calls arrives through xtensa_swint(), which has already recorded the caller's frame in xcp.sregs; that frame is used instead, because the caller is on the far side of the boundary.

The windowed ABI needs care in one place. A stack pointer has a base save area 16 bytes below it holding the caller's spilled a0–a3, and the frame chain runs through it. SPILL_ALL_WINDOWS puts the register file into memory first, and the chain is then walked and rebased onto the child's copy, because a frame pointer that still points into the parent's stack would send the child back into memory it does not own.

Impact

Xtensa gains vfork(). Nothing else changes, and no board configuration changes.

fork() is not provided here. That needs an address environment and arrives in part three.

Testing

Host: macOS 15 on Apple Silicon, xtensa-esp32s3-elf-gcc and xtensa-esp32-elf-gcc, both 12.2.0.

Three boards ran ostest to the end.

board	module	core	configuration	result
ESP32-DevKitC V4	ESP32-D0WD-V3 rev 3.1	LX6	`esp32-devkitc:ostest`	`vfork()` passes, status 0
ESP32-S3-DevKitC	ESP32-S3-WROOM-1 N8R2, 8 MB, DIO	LX7	`esp32s3-devkit:ostest`	`vfork()` passes, status 0
ESP32-S3-DevKitC	ESP32-S3-WROOM-2 N32R8V, 32 MB, octal	LX7	`esp32s3-devkit:ostest`	`vfork()` passes, status 0

The 32 MB octal part also needs ESP32S3_FLASH_MODE_OCT and ESP32S3_SPI_FLASH_USE_32BIT_ADDRESS.

user_main: vfork() test
vfork_test: Started
vfork_test: Child 5 ran and exited before the parent resumed
ostest_main: Exiting with status 0

Both Xtensa cores that NuttX supports are covered, and the LX6 has no MMU at all — which is the case this part is meant to serve.

tools/checkpatch.sh -c -u -m -g reports no errors.

The ostest split this needs, apache/nuttx-apps#3685, is merged, so the depends-on line is gone.

github-actions · 2026-08-11T14:28:57Z

MemBrowse Memory Report

esp32-devkitc

ROM: .flash.text +32 B (+0.0%, 124,700 B / 4,194,272 B, total: 3% used)
dram0_0_seg: .dram0.bss +16 B (+0.2%, 9,916 B / 180,736 B, total: 5% used)
irom0_0_seg: .flash.text +32 B (+0.0%, 88,904 B / 3,342,304 B, total: 3% used)
No memory changes detected for:
arduino-mega2560
hifive1-revb
mirtoo
qemu-armv8a
qemu-intel64
rx65n-rsk2mb
s698pm-dkit
stm32-nucleo-f103rb

casaroli · 2026-08-11T20:21:39Z

This work is now in #19798, together with the ESP32-S3 chip code and the user mode isolation that a kernel build needs.

Please review #19798 instead of this one.

This pull request stays open for reference, and it will be closed when #19798 is merged.

github-actions · 2026-08-11T22:45:00Z

🔗 Cross-repo PR dependencies

The read-only Build run reported the following dependent PR(s) and fetched head SHA(s):

testing/ostest: Split the fork test into vfork and fork. nuttx-apps#3685 @ 2a43c6dae9

CI run: https://github.com/apache/nuttx/actions/runs/31531206452

github-actions · 2026-08-20T12:08:36Z

❌ Cross-repo dependency could not be applied

The Build report says the declared dependency PR(s) could not be applied, so CI did not run against the combined code:

testing/ostest: Split the fork test into vfork and fork. nuttx-apps#3685

Reason: cherry-pick failed (if your PR has merge commits, rebase instead)

CI run: https://github.com/apache/nuttx/actions/runs/32367174417

xiaoxiang781216 · 2026-08-28T00:30:31Z

+   * this is how it reaches the registers of the thread that called it.
+   */
+
+  tcb->xcp.sregs = regs;


but tcb->xcp already save regs?

yes, xcp.regs holds it during the exception, but xtensa_irqdispatch.c sets it back to NULL on the way out, "to avoid misusage".

up_fork is itself the syscall, so its body runs as normal C after the exception has returned, and xcp.regs is NULL by then. that is what sregs is for anyway, right?

it is the same thing armv7-a does, arm_syscall.c sets rtcb->xcp.sregs = regs and arch/arm/include/armv7-a/irq.h declares the field.

I will move it into the default case and guard it the same way as arm.

Xtensa selected neither fork primitive, so vfork() was simply absent. This wires it onto the two-primitive semantics. There is no assembly entry point and none is needed. Every exception entry already runs SPILL_ALL_WINDOWS, so the whole context of the calling thread is in its exception frame and copying its stack copies a complete frame chain. A flat build reaches that frame through SYS_save_context, issued inline so that the recorded stack pointer belongs to a frame that stays alive for the whole operation; a build with syscalls reaches it through xcp.sregs, recorded by xtensa_swint() for the duration of the call. The stack copy needs more than a relocated stack pointer here. A windowed ABI stores each frame's caller stack pointer absolutely, in the base save area below the frame, so a copy taken at a different address still names the parent throughout and the child's first retw would underflow onto the parent's stack. xtensa_fork_rebase() walks that chain and adds the relocation offset to each link. The copy also starts one base save area below the stack pointer rather than at it, because the frame the child resumes into keeps its caller's spilled a0-a3 there. Ported from the per-architecture work, reduced to the two primitives. Co-authored-by: Xiang Xiao <xiaoxiang781216@gmail.com> Assisted-by: Claude Opus 5 (1M context) <noreply@anthropic.com> Signed-off-by: Marco Casaroli <marco.casaroli@gmail.com>

casaroli mentioned this pull request Aug 11, 2026

[2/3] mm/pgalloc, arch/xtensa: Support BUILD_KERNEL on Xtensa #19796

Draft

github-actions Bot added Arch: xtensa Issues related to the Xtensa architecture Size: L The size of the change in this PR is large labels Aug 11, 2026

casaroli changed the title ~~arch/xtensa: Provide vfork()~~ [1/3] arch/xtensa: Provide vfork() Aug 11, 2026

casaroli marked this pull request as draft August 11, 2026 14:23

simbit18 requested review from eren-terzioglu, fdcavalcanti, tmedicci and xiaoxiang781216 August 11, 2026 14:40

casaroli force-pushed the xtensa-split-1-vfork branch from 87d1d68 to af62cf0 Compare August 11, 2026 14:58

casaroli marked this pull request as ready for review August 11, 2026 15:00

This was referenced Aug 11, 2026

[3/3] xtensa/esp32s3: Per-process address environments and POSIX fork() #19797

Draft

arch/xtensa: Provide vfork() and fork(), and BUILD_KERNEL on the ESP32-S3 #19772

Draft

casaroli force-pushed the xtensa-split-1-vfork branch from af62cf0 to 27547e0 Compare August 11, 2026 20:05

casaroli mentioned this pull request Aug 11, 2026

xtensa/esp32s3: Run user processes in a world they cannot escape #19798

Draft

casaroli marked this pull request as draft August 11, 2026 20:21

casaroli marked this pull request as ready for review August 14, 2026 09:22

xiaoxiang781216 previously approved these changes Aug 18, 2026

View reviewed changes

Comment thread arch/xtensa/src/common/xtensa_fork.c Outdated

acassis previously approved these changes Aug 20, 2026

View reviewed changes

acassis dismissed stale reviews from xiaoxiang781216 and themself via e6cdfde August 20, 2026 12:06

casaroli force-pushed the xtensa-split-1-vfork branch from e6cdfde to 25066b2 Compare August 27, 2026 15:04

acassis previously approved these changes Aug 27, 2026

View reviewed changes

xiaoxiang781216 reviewed Aug 28, 2026

View reviewed changes

casaroli dismissed acassis’s stale review via a931ae3 August 28, 2026 09:59

casaroli force-pushed the xtensa-split-1-vfork branch from 25066b2 to a931ae3 Compare August 28, 2026 09:59

xiaoxiang781216 approved these changes Aug 28, 2026

View reviewed changes

acassis approved these changes Aug 28, 2026

View reviewed changes

Navigation Menu

Uh oh!

[1/3] arch/xtensa: Provide vfork() - #19795

[1/3] arch/xtensa: Provide vfork()#19795
casaroli wants to merge 1 commit into
apache:masterfrom
casaroli:xtensa-split-1-vfork

casaroli commented Aug 11, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Aug 11, 2026 •

edited

Loading

Uh oh!

casaroli commented Aug 11, 2026

Uh oh!

github-actions Bot commented Aug 11, 2026

Uh oh!

Uh oh!

github-actions Bot commented Aug 20, 2026

Uh oh!

xiaoxiang781216 Aug 28, 2026

Uh oh!

casaroli Aug 28, 2026 •

edited

Loading

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

casaroli commented Aug 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Impact

Testing

Uh oh!

github-actions Bot commented Aug 11, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

MemBrowse Memory Report

esp32-devkitc

Uh oh!

casaroli commented Aug 11, 2026

Uh oh!

github-actions Bot commented Aug 11, 2026

🔗 Cross-repo PR dependencies

Uh oh!

Uh oh!

github-actions Bot commented Aug 20, 2026

❌ Cross-repo dependency could not be applied

Uh oh!

xiaoxiang781216 Aug 28, 2026

Choose a reason for hiding this comment

Uh oh!

casaroli Aug 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

casaroli commented Aug 11, 2026 •

edited

Loading

github-actions Bot commented Aug 11, 2026 •

edited

Loading

casaroli Aug 28, 2026 •

edited

Loading